原本表定的 Day19 是要談 [SQL 語法轉換紀實]，剛才提筆要寫才發現，前幾天好像已經大部分都講完了，真是人算不如天算。那就把預計明天要寫的內容拿來寫吧，不過 Store Procedure 的除錯技巧還不少，也許可以分為2天來寫，就請各位看官將就看看吧。

Store Procedure 並不是萬靈丹，這個我必須說在前頭，就像其他程式語言一樣，他有很多優點，但是缺點也不少。他的缺點主要可以從三個方向來說

• 每一個資料庫都有自己的專屬語法(也就是方言)，這會造成轉換資料庫的困擾
• 非物件導向語言
• 除錯困難，無 IDE 環境可以下中斷點除錯

當然，也許其他人員會說他的語法不嚴謹之類，但是以我的實務經驗看來，這問題不大，所以我就沒有列出來。
在上面這三點中，第一點我們已經在前文討論過，實務上，轉換資料庫的情況並不多見，我個人的看法是「慎選資料庫、一門深入」，一旦選定，就買定離手，不要輕易更換，那這個問題就不大。就算萬不得已要換，以我的個人經驗，只要真的對某一個資料庫下過苦功，要在短期內搞懂另一個資料庫並不難。請各位參考前面的幾篇文章應該就可以理解。

至於第二點，非物件導向語言。這就真的是見仁見智了。有些 Developer 認為程式開發語言，都已經被物件導向統一了，但是一接到資料庫的 SQL 程式，就好像回到原始人的世界，滿心的圈圈叉叉。關於 ORM 我在後面的單元，有專文討論，這邊就簡單說明帶過。

所謂的 ORM，即 Object-Relational Mapping(對象關係映射)，它的作用是在關係數據庫和業務實體對象之間作一個映射，這樣，我們在具體的操作業務對象的時候，就不需要再去和複雜的SQL語句打交道，只需簡單的操作對象的屬性和方法。

我個人實際的經驗，這的確是有一點不順，但並不嚴重，尤其 RESTFul API 架構興起後，我甚至用 Store Procedure 寫了一支通用的 orm_api，可以幾乎完全取代 ORM 的大部分功能，重點是，完全不需要安裝、學習任何的 ORM 框架。當然，這只是我的個人經驗，後面會再詳細說明。

我也研究過幾套 ORM(Nhibernate、EF)，功能也都還不錯，配合一些工具，甚至 MVC 架構的 Model 都能自動產生，看起來是很方便。可是對於像我這樣的 SQL 重度使用者來說，用 ORM 真的有隔靴搔癢的嚴重不適感。我想應該有很多重度 SQL 使用者會感同身受，明明一句 SQL 就能簡單搞定的事，用 ORM 就變成天大地大的難事，所以也才有了本系列文的產生。

我認為任何的語言，如果經過幾十年仍能屹立不搖，就一定有其存在的必要性。SQL 語言事實上已經存在很久了，我一直有一個很大的疑惑，為甚麼在程式設計這個領域，永遠都是革命、創新會受到追捧，原有的語言卻只能拋棄? 我個人認為 Borland 的 Delphi 系列，是地球上最佳開發工具(我還在使用 Delphi 7，目前的 XE 太晚推出，很難有大作為)。但是又如何? 我後來也只能改用 Visual Studio 20xx，現在重新學習 Vue + Element UI 中。好了，就只是發發牢騷，別佔太多篇幅。

簡單的結論，我認為非物件導向並不是重大的 issue，但是如果堅持要全面使用物件導向，那就請繞道。不過讓我們面對現實，SQL 短期內還是無法被替代，有些複雜的計算，如果不透過 SQL 而用前端來處理，會付出效能的代價。所以，我會繼續努力地用 SQL，並想辦法讓所有的事情都用 SQL 解決，前端對我而言，就是介面處理。這是最有效率的分工。

再來就是第三點，除錯困難，無 IDE 環境可以下中斷點除錯。
這是事實，而且我認為這才是阻礙 SQL 推廣的最大問題，就算我已經算是資深的 SQL Developer，還是會常常陷入除錯的誤區，等到千辛萬苦解決問題後，除了無語問蒼天外，很難有其他的想法。

Store Procedure 的除錯，通常有下列幾個方式，我先條列出來，明天再繼續詳細說明(耶，進度打平了)

• print 就是最常用的 alert
• 將有問題的程式片段 copy 到 Database4 中，mark 部分程式重複執行
• 寫到 log 暫存檔
• 查看錯誤訊息紀錄

今天先談到這邊，明天繼續努力。